The Business Master (3rd Edition)

home *** CD-ROM | disk | FTP | other *** search

/ The Business Master (3rd Edition) / The Business Master (3rd Edition).iso / files / commadio / pk232com / g3zcz.lan < prev next >

Wrap

Text File | 1987-11-09 | 39.9 KB | 925 lines

PACKET RADIO - THE USER INTERFACE PAGE 1 Presented at the AMSAT-NA 1987 Space Symposium. PACKET RADIO - THE USER INTERFACE By Joe Kasser G3ZCZ Introduction The majority of the thinking and the software development in Packet Radio to-date has been in the area of the BBS and in message handling. Everyone assumes that messages exist yet ignore how those messages got into the packet radio network in the first place and how they get out of it later. This paper addresses that neglected aspect of the gendre; in other words, the User Interface or the Personal Packet Terminal Program (PPTP) and the environment in which it resides. The Packet Radio Medium. The Packet Radio Medium consists of what is happening in a given local area on a frequency channel time-shared by a number of amateur radio stations. It is a multiple access or distributed situation which has so far been treated almost the same as a single point-to-point situation such as the telephone line. Unlike in a telephone based network, many of the stations in the network can, in real time, see information passing between other stations in that network. [1,2] Whereas the telephone based net may be considered as a centralized network in which everyone on it is connected to a single host, the amateur radio packet Local Area Network (LAN) is spread over a geographical area and should be considered as a distributed network. Packet Radio software to- date has been designed for a one-on-one connection ignoring the one-on-many capabilities available in a distributed LAN. Consider the medium itself, Packet Radio is an ideal MESSAGE MEDIUM. While there is place for keyboard operation, Packet Radio really shines when passing messages. The Packet Radio operator is really interacting with the LAN. The TNC and PPTP can be considered as a single element between the human operator and the LAN, so that any discussion of the user or human interface must take into account activity on the LAN. Packet Radio LAN Capability VHF Packet radio systems can be considered as part of a LAN in which messages can be left by one station in a computer belonging to a second station. At HF the same is true, but the area of the LAN becomes greater. The fundamental problem within the LAN is that people can only send and receive messages to or from any specific station when that station is on-line. To compensate for this, Packet LAN (c) Joe Kasser 1987 PACKET RADIO - THE USER INTERFACE PAGE 2 development parallelled that of the centralized telephone network. BBS stations were developed which allowed both messages and bulletins to be stored for later retrieval. As the requirement for bulletin messages is real in the Radio Amateur environment and the centralised LAN concept meets the requirements of both bulletin and point-to-point messages, the distributed LAN approach for point-to-point messages in the main seems to have been ignored. Most Amateur Packet Radio Stations use computers to interface the TNC to the LAN. As there is all this computer power sitting in the shack, why not take advantage of it.Let us include within the PPTP software, which takes into consideration both the characteristics of the distributed LAN and how optimum use can be made of them for the user. The User Interface. This is defined as what the user types at the keyboard and sees on the screen of his computer when it is connected to a working TNC which by definition is part of the LAN. When somebody first gets a TNC, he gets a 'black box' which comes with a manual that seems bigger than than the box itself. The instructions on how to connect it to a transceiver may be easy enough to follow, but then the instructions on what to type and when, are a nightmare. The TNC can operate in a Command Mode, in which you tell it to do something, or in a Converse Mode in which you are using it to pass text of some kind to other stations. Many newcomers confuse the two TNC modes. If you monitor the packet channels you will recognize command mode TNC instructions on the air, and when you use the TNC, well I'm sure that you still get, now and again, an 'Error' message when you type something thinking that you are in the Converse Mode but are really in the Command Mode. The Personal Packet Terminal Program [PPTP]. Most of the commands that affect the parameters within the TNC are normally never touched. In fact once 'CONNECT', and 'DISCONNECT' have been figured out, and the difference between the Command and the Converse Modes (and how to get from the one to the other) are understood, the newcomer is able to use Packet Radio. From this time on he rarely uses any of the other TNC commands with the possible exception of 'MH'. Even the ones that should be adjusted when changing from VHF to HF operation most often never are. From a human factors point of view, Packet Radio under these conditions is dissapointing. Tests have shown that the attention span of a person sitting at a terminal is about 2 seconds. In conventional RTTY, or AMTOR operation, the data communications rate is might be slow but at least something is happening all the time. In keyboard to keyboard Packet Radio contacts, often minutes seem to pass before the next packet shows up on the screen. The PPTP's most commonly used at present on PC's are either YAPP (c) Joe Kasser 1987 PACKET RADIO - THE USER INTERFACE PAGE 3 [3] or conventional telephone modem driver programs. There is no smart PPTP. The need for "smart" PPTP's is however being perceived. The Mini BBS seen on the air is one example. Another example noticed in London and in Israel, is that stations equipped with IBM PC's or clones start off by using BBS programs as their PPTP. On one evening in London in August 1987 G3RWL taped about 10 BBS's, point to point direct connects, stations doing muti digipeat connects to other stations as well as to the BBS's all on the same channel and all using it simultaneously. It is a wonder that any traffic got through. A PPTP program written in Turbo Pascal, named PK232COM, that is optimized for the radio amatuer LAN has been developed for the MS- DOS, IBM PC series of microcomputers. Although first written for the AEA PK232 Multi-Mode Data Controller, taking advantage of some of the specific commands built into the PK232. It has since been modified so that most of the PPTP Packet Radio functions will also work on a TNC2. The following list contains much of what this PPTP does both as the user interacts with it, and how it performs LAN related activities. * Function Key Control The commands to the TNC lie somewhat in between a mixture of operating, configuring and debugging. This PPTP relieves the user of figureing out how to tell the TNC to do what he wants it to do. It takes advantage of all the computing power at the user's fingertips (literaly) and uses software which may be located either in the TNC or in the PPTP, but totally transparent to the user. The user in fact never has to tell the TNC to go into or out of the command or converse modes. The user tells the PPTP what he wants done by means of function keys, and the PPTP figures out what to tell the TNC to do the job. * Terminal modes. There are four single connect modes and two multiple connect modes of operation, as follows. 1 SOLO In this mode, you will only see messages addressed to you. You will only get messages from people who connect to you. (This corresponds to 'MONITOR OFF'). 2 TRAFFIC In this mode you will see most of the traffic on channel. You can use this mode to check that the TNC is working. (This corresponds to the PK232 'MONITOR 4' [4] or 'MONITOR ON'). (c) Joe Kasser 1987 PACKET RADIO - THE USER INTERFACE PAGE 4 3 CQ/BEACON In This mode, you will see CQ and BEACON packets on the channel. (This corresponds to the PK232 'MONITOR 1' and only works on the PK232. 4 READ THE MAIL In this mode the terminal is set to display the contents of packets without the headers for selected stations. Apart from being able to copy both sides of a QSO, you can read the mail on a BBS or other stations and get BBS bulletins without connecting to that BBS your self. This cuts down on the number of messages sent on the LAN, since more than one station can copy the same Bulletin at the same time. This corresponds to 'MONITOR OFF' and 'MBX' <callsign> and only works on the PK232. 5 MULTIPLE CONNECT CAPABILITIES Advantage is taken of the 10 I/O streams in the TNC for multiple access modes as follows; 5.1 The Individual Multi Connect Mode This is the normal Multi Connect Mode as described in the TNC manual. Here you are connected to up to 10 stations and will send different traffic to each of them. Each time you wish to send something to a particular station, you must select the IO channel the station is connected on before typing the text or sending the file. 5.2 The Conference Multi Connect Mode. In the Conference Mode on the other hand, everything that you type at the keyboard is transmitted to each station that you are connected with. Thus if you are linked to two stations each line will be packeted twice by the TNC. You don't have to worry about sending the wrong thing to the wrong person, as they will all get the stuff. This mode should be ideal for DX nets, 'contest spotting' and public event support. * Automatic Answering Machine capability with display of message queue. The PPTP incorporates a smart "answering machine" facility. You can leave messages on your system for different stations. When someone connects to you, if you left a message for him, he (or she or even it as the case may be) will receive it automatically. No one else should normally be able to download that message. To ensure that people know that you have left a message for them, a 'MAIL for' list is loaded into your Packet Beacon and (c) Joe Kasser 1987 PACKET RADIO - THE USER INTERFACE PAGE 5 transmitted every 30 minutes. If no mail is pending then beacon transmissions are inhibited. This conforms to good operating practice on crowded channels (at least inhibiting the beacon does). * Automatic Capture-to-Disk All traffic received during connects is stored onto disk. Provision is also there for manual capture of any traffic monitored on the screen. * Automatic logbook entries for Connects. All connects are logged into a separate logbook file. The Logbook file is capable of being processed by a database Logbook Package. * Printer on/off control. The PPTP can print incoming information and will automatically shut off the printer on disconnect. * Alert signal The PPTP contains an Alert function to let you know when someone shows up on LAN. It is active when disconnected and the terminal set for 'TRAFFIC'. The PPTP scans the packet headers received from the TNC, and, when it sees a packet originated (or digipeated if the MRPT parameter in the TNC is set to 'ON'), by the station whose call has entered as the 'Alert' call, sounds an alarm at the console. The Alert function should (but can't be without getting at the TNC firmware) be independent of the terminal communications mode. * Indicator that a specific station designated as the 'target' call connected while you were away. This function saves you dumping the capture-to-disk file to check if traffic has been received from a particular station who promised to send you some data that you need urgently. * Split screen terminal display, at least 3 Windows displaying Incoming text, Outgoing text and Status Information. The Status information includes the call of the Station you are connected with (if any), PPTP mode and status, number of connects, number of messages outstanding, PPTP configuration, Alert and Target calls. When the PPTP sees a connect by the station whose call you have entered as the 'Target' call, it sets the flashing Connect Counter display to show a 'happy face'. (c) Joe Kasser 1987 PACKET RADIO - THE USER INTERFACE PAGE 6 * Simplified keystrokes for connect paths and loopbacks. Connect path information may be stored in an ASCII text file (PK232COM.DIR which is compatable to YAPP.DIR [3]) in the following format. Alon 4Z4ZB V 4X6AA Milt 4X6AA LR 4X6LR hf-il 4x4hf v 4z4zb 4x4il hf-rj 4x4hf v 4z4zb 4z4rj You create this file with your wordprocessor in its non document mode. You must leave AT LEAST one space character between the key word and the connect path. When you attempt a connect, the PPTP scans this file to see if what you typed matches one of the key words (first word) on any line of the file. It also ignores the case of what you typed in. If it does not find the key word, it will try to connect with whatever you typed in. A LOOPBACK is when you connect to yourself through someone else. You should use this to test a connect path when the station you want to connect with is connected to a third station. Instead of causing QRM to him by trying to connect to him and getting a 'busy' signal if the path is good, loopback using him as a digipeater to test the path. The loopback should be performed with a minimum of keystrokes. Thus to loopback through K8PNW you just have to use the regular PPTP function key that does the connect operation (Function key 7), but type '/K8PNW' (slash [callsign] instead of [yourowncall] via [callsign]). * Path determination to Dx station. On VHF, if you want to establish a digipeat path to a station somewhat out of your direct range, you need to know which of the stations that you can connect with can hear that desired DX station. If you could get a call monitored (MH list) from the stations that you connect with, you would be able to see if the station you are connected with has heard your desired DX station. Thus as the TNC can't do it, the PPTP is capable of being triggered to send its 'MH' list to the connecting station. By judicious use of this capability you can determine paths to other stations. Note however, that just because one station can hear another station, it does not mean that it can work it. For example, the station you are connected with may be using a power level of 1 watt or so, while the station 200 miles away that it heard was using 100 watts. Test the path yourself, or/and leave a message asking about the reliability of the connect path between those two other stations. The DX station also may not be on-line all the time. (c) Joe Kasser 1987 PACKET RADIO - THE USER INTERFACE PAGE 7 * Remote File Downloading There comes a time when you want to leave a file on your system for someone to download later. For example, you have the latest AMSAT or ARRL DX bulletin, and you want to pass it on. You could pass it to selected people by copying the file to individual messages which wastes a lot of disk space. On the other hand you could tell people that the file was available for downloading. You could do this either in the CTEXT connect message line which everyone gets when connecting to you, or in individual messages if you don't want everyone to know about it. The PPTP is not designed as a BBS, however it does have the capability for remote downloading of files. * Automatic Count of, and indication of Packet connects. The counter shows the number of connects made to the PPTP since you last reset the counter. Its a usefull indicator of how much trafic has come in since you last looked at the screen. The counter is resetable by means of a function key. * Digipeat monitoring and capture. Although the TNC can digipeat on its own, there may be times when you want to know when you are being used as a digipeater and to capture-to-disk the contents of any packets digipeated through your station. (A typical example of this situation is when stations on your 'forbidden country list' digipeat through you and you may have a need to show what data was "exchanged".) This capability is in the PPTP. * Capable of automatic connect attempts to snatch a QTC. In the disconnected state, the PPTP monitors 'QTC' lists and when it sees its own call in one, automatically attempts a connect to snatch the message. In this manner there is no need to manually repeat connect requests to stations to whom messages are addressed in the hope that they have joined the LAN. When any station signs on to the LAN (ie the time when the equipment is powered up), it will, within 30 minutes, monitor a QTC list from every other station on the LAN and download its own traffic. In fact in an ideal situation, all one would have to do to "send" a message would be to leave it in one's own PPTP which would then set the QTC list in the Packet Beacon. The QTC_Snatch in the destination PPTP function would take care of the message transfer. In the PACSAT environment, the QTC_Snatch function would be used to automate reception of messages at remote ground station sites. When the spacecraft is within the communications window of a ground station for which it has traffic for and transmits a beacon 'QTC mail-for' list, the (c) Joe Kasser 1987 PACKET RADIO - THE USER INTERFACE PAGE 8 ground station will automatically download its traffic. As the QTC_Snatch may not be legal in certain countries, this capability is only configurable at the time of loading the program and is not reconfigurable on-line. * Automatic Beacon Mode CQ caller. The PPTP has the capability to call CQ repetitively and either signal you when a reply is received or work the connect and call CQ again after the disconnect. This ROBOT feature is designed for DX-Peditions, special event stations, meteor scatter, moonbounce, propagation research beacons, areas of low activity and to enable "off- channel" or random frequency HF Packet operation. In case of abuse: if someone running the PPTP has their beacon timer set too often, the PPTP can be shut down remotely by someone connecting with it and telling it to 'QRT'. This takes them off the air for a while at least. * Local Area Network (LAN) message store and forward. The PPTP is capable of storing messages to be delivered in the manner of a 'selective' answering machine. When someone connects, any message pending is delivered without the need for any further action. In case of some error a 'repeat request' function is available. All stations in the LAN should in the ideal case be able to store messages for any other station in the LAN. * Bulk dump (forwarding) of messages around the LAN. There are many instances when the owners wish to take their systems off-line yet still wish that their messages be posted in the LAN. The PPTP thus contains a facility for bulk 'dumping' of messages between different computers in the LAN. LAN Protocol (G3ZCZ Version) The LAN has to be usable by all stations connected within it no matter how smart or dumb a PPTP they are running. The commands thus should be manual as well as function key driven. The language used should be reasonably familiar to Radio Amateurs and be capable of being used by those with little or no knowledge of English. In the G3ZCZ LAN environment, path determination and other functions as well as messages transferrence may be performed using elements of the Q code adapted into a High Level Network Communications Language (NC/L) [1,2]. (c) Joe Kasser 1987 PACKET RADIO - THE USER INTERFACE PAGE 9 To receive a message, do nothing, you receive them automatically when connecting/linking to another station. In case of a problem you may request a repeat. You should also normally not be able to read messages adressed to another person. Bulletins are not considered as messages, they are considerd to be files. NC/L uses elements of the Q code in CAPITAL letters with a ':' character prefix and suffix (eg. :QSL:), so as not to trigger responses in text. The PPTP does not respond to lower case NC/L to allow 'help' information to be transmit- ted on-the-air without also triggering a response. Elements in use to-date in PK232COM Version 1.43 are (in alphabetical order) as follows. :EOF: End of message, (^Z is used in Packet, :EOF: is used in AMTOR). :QBM: To download a file. :QJG: No more messages pending. :QMH: To request a call monitored list ('MH'). :QNO: Error or function not present/active. :QRV: Ready for message. :QRT: To shut down a packet mode beacon station. :QRU: To upload messages. :QSL: Confirm receipt. :QSM: To request a repeat of a message. :QSP: To leave a message for another station. :QTC: Messsage list. Proposed extensions are as follows. :QYU: YAPP format (binary) file upload. :QYD: YAPP format (binary) file download. NC/L In Use. All command words in NC/L if requiring an extension, are followed by one space character. The following words are transmitted to a remote PPTP. :QBM: To download a file, send :QBM: filename.type. The filename.type is the file you want. For example :QBM: ARRLDX.015 Note the single space character between :QBM: and the file name. The PPTP is not designed as a BBS, however if you leave a file or bulletin for someone to download, you may tell them about it by leaving them a message (which they will get automatically when they connect) and no one else connecting will know that it is there. (c) Joe Kasser 1987 PACKET RADIO - THE USER INTERFACE PAGE 10 :QMH: To request a call monitored list ('MH') from the station that you are connected with, send :QMH:. :QSM: To request a repeat of a message, send :QSM:. You use this if the link was marginal and the connect request got through but the data didn't. :QSP: To leave a message for someone, send :QSP: callsign. The protocol is as follows. When connected to someone who has their computer configured as a host, if you want to store a message you send the following instruction to the other station :QSP: <callsign> where <callsign> is the call of the station that the message is for, not the callsign of the host station in whose computer you are storing the message. Do not use SSID's. [Note use only one space character after the :QSP:]. For example if you want to store a message for 4Z4ZB, or 4Z4ZB-1 or even 4Z4ZB/W3 in 4X6AA's computer which is configured to Store and Forward messages, you would first connect to 4X6AA and then send the request to store the message as :QSP: 4Z4ZB . The other computer will respond either with a statement saying that it is ready for you to go ahead, or send a message saying that it can't comply. If it is ready you get a positive reply in the the form of :QRV: <callsign> which if you know the Q code, means " I am ready to accept a message for <callsign>". At this time you may go ahead and send the message. Use either a control Z (^Z) character or the character sequence :EOF: followed by a carriage re- turn (the ENTER key) to terminate the message. Once you have completed the message, the other (host) computer will either reply that the message has been successfully stored or give you an error message. If the message is stored and ready to be sent next time the addressee connects to that computer, you will see the response :QSL: on your screen. If something went wrong, you will get back a negative response taking the form :QNO: followed by a number. The number tells you why the operation failed. :QRT: To shut down a packet mode robot or beacon station which is causing QRM, connect with that station and tell it to 'QRT' by sending :QRT:. (c) Joe Kasser 1987 PACKET RADIO - THE USER INTERFACE PAGE 11 :QRU: To upload or download messages from one PPTP to another, send :QRU:. When the QRU function is invoked locally or remotely, either by you or for example, by 4Z4ZB connecting to you and sending you the command :QRU:, any messages addressed to any stations for which you have designated him as a 'Store and Forward' node (MBX) will be transferred from you to 4Z4ZB just as if you QSP'd the messages manually. You may only use the QRU function with stations which you have pre-designated as Store and Forward nodes (MBX). Everybody designates their own Store and Forward nodes based on the 'MH list' of the station being designated. The is little point in designating someone as a 'Store and Forward' node for stations that they cannot connect with, unless they happen to be in a digipeat path for inter LAN message passing. While QRU gives you the capability to bulk upload messages to another station in your local area, when you take your machine off line, it may also be used to transfer messages between two LANs (such as the Baltimore and Washington DC Areas) via well sighted gateway digipeaters. It can also be used for long distance transfers but in a very inefficient manner. :QNO: 'NO' or error QNO Error Values. The following error numbers are associated with message store and forward operations. ? Non valid NC/L word. 1 Computer not configured as Store and Forward system. 2 Requested ASCII file/ message (:QBM:) does not exist. 3 You made an error in the name of the callsign for whom the message is intended (It must be at least 3 characters long). 4 File creation error in host system. 5 Error occurred during reception and storage of message. Could be that the computer ran out of space on the disk, or something else went wrong in storing the message. 6 :QRU: You are not authorised as a store and forward mailbox. 7 :QRU: Error in opening MBX file. 8 :QRU: Error in closing MBX file. 9 :QRU: Sequence Error in callsign of message to go. The bad callsign will be shown after the error number. (c) Joe Kasser 1987 PACKET RADIO - THE USER INTERFACE PAGE 12 90 NC/L defined function not implemented in this release. 99 PK232COM compatable program, but requested function has not been implemeted. :QJG: The QRU sequence is complete. There are no more messages pending. :QRV: <callsign> The computer is ready for you to send the message. End the message with a control Z (^Z) character, or the sequence :EOF: . :QSL: <callsign). Confirms receipt of message to that callsign. :QTC: Messsage list. This precedes a list of callsigns for whom messages are stored up on a computer. It is used in Packet Beacon transmissions. PROPOSED EXTENSIONS :QYU: YAPP format file upload. :QYD: YAPP format file download. Message Format When you QSP a message, it is stored just as if you had left it in your system (except that a header is added identifying the time of reception and the call of the sending station). Should a message for that station already be in the system, yours should be appended to it. In the event the your upload is aborted, the amount of text received before the abort occurred should be stored as the message. There should also be a stored note within the message stating that the upload was aborted. When you disconnect from the host station, its beacon will be updated. Once the message is loaded in the host, it can only be deleted by the operator of the host station. PK232COM Version 1.42. All this and more is available for the IBM PC and clones in the shape of PK232COM Version 1.42. As the program was first written for the AEA PK232 TNC, and the data throughput at HF seems better using AMTOR, it also contains AMTOR related robot functions. (c) Joe Kasser 1987 PACKET RADIO - THE USER INTERFACE PAGE 13 In this version of the program most of the packet features described herein can be used by those owners of TNC2's or compatables. The major development, debugging and testing of PK232COM (Versions 1.00 to 1.41) took place in Jerusalem in the summer of 1987. There the ROBOT station G3ZCZ/4X using just an FT-101 and a dipole antenna operated on an intermittent shedule mostly overnight and on weekends mainly on 20 Meters AMTOR and Packet until the power supply transformer in the FT-101 smoked. Amongst its achievements were; * WAC in both Packet and AMTOR communications modes. * It worked nearly 50 countries each on both AMTOR and Packet. The computer said that it made 663 Packet connects with 371 different stations, and 526 AMTOR links with 330 different stations. It even worked countries that I still I haven't, usually because propagation was only present late at night or very early in the morning, local time. * A 10 day long AMTOR QSO between G3ZCZ/4X and VU2IJ in which VU2IJ would link up, receive his message and leave a reply which would be answered the following day. * The first intra-Jerusalem (perhaps even intra-4X) AMTOR QSO which took place between G3ZCZ/4X and 4X6AA. The unusual part of the QSO was that both G3ZCZ and 4X6AA were operating 4X6AA, while the Robot was operating at G3ZCZ/4X. * Pioneer Robot Propagation Beacon Experiment. The Robot put out a CQ every 2 to 4 minutes when active. This must have been the world's first HF Beacon station that could receive propagation reports from listeners in real time. This was not a mailbox. Whereas I (the beacon keeper) could leave messages for anyone and did, others could only leave them for me. Several stations contacted commented that they used the robot as an indicator of propagation, and I could tell by the log when propagation was present to DX areas. If such Robot beacons were to replace the existing IARU HF beacons, and were to be located in remote DX locations, I feel sure that the QSL hunters would be more than glad to work them and provide propagation reports in real time. Acknowledgements. I would like to acknowledge and thank the many radio amateurs around the world for their help, suggestions and patience in the design, testing and debugging of the many features of the prog- ram. (c) Joe Kasser 1987 PACKET RADIO - THE USER INTERFACE PAGE 14 References 1 From RTTY to Packets, Joe Kasser, G3ZCZ, First ARRL Amateur Radio Computer Networking Conference, 1981. 2 Software for Amateur Radio, Joe Kasser, G3ZCZ, published by TAB Books, Blue Ridge Summit, Pa. 17214 USA (Book number 1560). 3 YAPP, Yet Another Packet Program Version 2.0, Jeff Jacobsen, WA7MBL. 4 PAKRATT Model PK-232 Multi-Mode Data Controller Operating Manual, Advanced Electronic Applications, Inc. (c) Joe Kasser 1987